home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part1 / 5887 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.0 KB
  1. Path: nh.acorn.co.uk!uknet!str-ccsun!not-for-mail
  2. From: nbc@vulture.dmem.strath.ac.uk (Neil Brendan Clark)
  3. Newsgroups: comp.sys.amiga.misc
  4. Subject: Re: Acorn RiscPC --- a thought?
  5. Date: 19 Feb 1996 19:33:29 -0000
  6. Organization: University of Strathclyde
  7. Message-ID: <4gaja9$i1o@vulture.dmem.strath.ac.uk>
  8. References: <4fdglm$b8s@vulture.dmem.strath.ac.uk> <1996Feb12.152844.28437@leeds.ac.uk> <4fo381$c0t@vulture.dmem.strath.ac.uk> <1996Feb14.125120.13466@leeds.ac.uk>
  9. NNTP-Posting-Host: vulture.dmem.strath.ac.uk
  10.  
  11. J M Oldak <csxjmo@scs.leeds.ac.uk> wrote:
  12. >Neil Brendan Clark writes:
  13. >>J M Oldak <csxjmo@scs.leeds.ac.uk> wrote:
  14. >>>Neil Brendan Clark writes:
  15. >>
  16. >But it also means that, at the end of the day, the applications are more
  17. >efficient. 
  18.  
  19. No, it does not. You seem to have the idea that a pre-emptive MT system
  20. incurs some sort of vast overhead. This is simply not the case - the overhead
  21. is insignificant. It also means that applications are less portable. I have
  22. already gone into reasons why cooperative MT is *less* efficient - in a sense
  23. it could even be said to "poll".
  24.  
  25. >It might take a bit longer in development, 
  26.  
  27. i.e. less real devlopment gets done. One of the reasons for things like 
  28. pre-emptive MT (PMT?), virtual memory, and standard libraries is precisely
  29. to relieve the programmer of dealing with the drudgery of the underlying
  30. machine. This is not a new development in computer science.
  31.  
  32. >but being aware
  33. >of the limitations of the OS (I admit - it is a limitation) in this case
  34. >can, and does, lead to better programs.
  35.  
  36. You are correct to an extent, but what happens when a new revision of the OS
  37. or a new chipset comes along? All of the assumptions you have made may
  38. change. This happened on the Amiga; all the Co|)3rZ that wrote self modifying
  39. code (justifiable on a 68000) found that it broke on a 68020. It is the 90's,
  40. for god's sake; applications should be written to be as portable and hardware
  41. independant as possible. It simply isn't worth making tinpot optimiztions
  42. anymore for a few % increase in speed.
  43.  
  44. >This is certainly untrue in my experience. 
  45.  
  46. No, it is true. In a cooperative MT environment, there is no guarantee that 
  47. a process will *ever* give up the CPU, let alone respond immediately to an
  48. event, without special hacks. Imagine you have a program that "yields" once
  49. every second. While this is running in the background, you will have an
  50. average response time of ~0.5s for your foreground tasks. Not good.
  51.  
  52. >Faster than the X-windows interfaces we use at the uni, 
  53.  
  54. X is a whole different kettle of fish, designed to be network transparent and
  55. so on. This incurs a lot of overhead, but is worth it. As well as that, your
  56. home directory and various other things probably reside on a remote disk
  57. connected to your machine via NFS, which tends to reduce responsiveness a bit.
  58. Anyway, X on my P75 seems pretty responsive to me. Maybe I'm just slow ;-)
  59.  
  60. >and faster than Windows 95 on my dads 486 DX2-66, 
  61.  
  62. No surprises there...
  63.  
  64. >The PC has twice the MIPS of my Acorn - but the OS, combined with efficient 
  65. >programming of applications means that the Acorn is much more responsive.
  66.  
  67. Agreed. But Windows is shite anyway - you can't say something is good because
  68. it is better than something that is bad!
  69.  
  70. >>It must have some CPU arbitration mechanisms then?
  71. >I'll agree with you - if only on the grounds that I don't know what you mean...
  72.  
  73. I was wondering if there was anything "extra" in the MT model that RiscOS uses
  74. to ensure fairer task scheduling over and above that of cooperative MT.
  75.  
  76. >A little out of context. I'm talking about a fast preview of a JPEG on a single
  77. >user machine here. For a fast response time - it makes sense to single task
  78. >for a second, and then let everything carry on...
  79.  
  80. This is getting religious - I'm afraid we're going to have to agree to disagree
  81. on this point.
  82.  
  83. -- 
  84. "I have trouble imagining death at that income level" - White Noise, D.Delillo
  85.  
  86.                  Neil Clark, Transparent Telepresence Group
  87.                   <http://telepresence.dmem.strath.ac.uk/>
  88.